<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Walter Hamscher (Standard Advantage) -->
<!-- XBRL 2.1 Tests -->
<!-- Copyright 2003 XBRL International. All Rights Reserved. -->
<?xml-stylesheet type="text/xsl" href="../../testcase.xsl"?>
<testcase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="XLink Label" description="Section 5.5.7.8 Arc equivalence 5.5.7.8" outpath="out" owner="dvunkannon@kpmg.com" xsi:noNamespaceSchemaLocation="../lib/test.xsd" minimal="true">
        <!-- 
Ensure that all locator elements resolve their href attributes to an XML Schema element element or an element that is a resource-type

Ensure that xpointer syntax in linkbase href attributes is properly flagged as an error.

Ensure the processor processes occurrences of the xml:base attribute correctly when resolving href attributes in locators 

Ensure that no two arcs in an extended-type link have the same “from” and “to” XLink label values even if their arcrole values differ (this is an XLink syntax constraint).  Note that the “from” and “to” concepts may be the same as long as they are denoted by locator elements having different xlink labels 
        -->
        <variation id="V-01" name="Arc-type element href resolution">
                <description>202.01 A URI reference appearing in an href attribute must resolve to an XML Schema element element or an xlink resource-type element</description>
                <data>
                        <xsd readMeFirst="false">202-01-HrefResolution.xsd</xsd>
                        <linkbase readMeFirst="true">202-01-HrefResolution-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-02" name="Arc-type element href resolution counterexample">
                <description>202.02 A URI reference appearing in an href attribute must resolve to an XML Schema element element or an xlink resource-type element</description>
                <data>
                        <xsd readMeFirst="false">202-02-HrefResolutionCounterExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-02-HrefResolutionCounterExample-label.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-02a" name="Arc-type element href resolution counterexample a">
          <description>202.02a an empty href resolves to a definite resource, which should be subject to source/target validation</description>
          <data>
            <xsd readMeFirst="false">202-02a-HrefResolutionCounterExample.xsd</xsd>
            <linkbase readMeFirst="true">202-02a-HrefResolutionCounterExample-label.xml</linkbase>
          </data>
          <result expected="invalid"/>
        </variation>
        <variation id="V-02b" name="Arc-type element href resolution counterexample a">
          <description>202.02b in the absence of source/target constraints, an empty href doesn't pose a problem</description>
          <data>
            <xsd readMeFirst="false">202-02b-HrefResolutionCounterExample.xsd</xsd>
            <linkbase readMeFirst="true">202-02b-HrefResolutionCounterExample-custom.xml</linkbase>
          </data>
          <result expected="valid"/>
        </variation>
        <!-- XML Base -->
        <variation id="V-03" name="XML Base Processing">
                <description>202.03 A URI reference appearing in an href attribute must be computed using the method described in XML Base [XMLBase].  Xsd specifies base for linkbase as "./base/".</description>
                <data>
                        <xsd readMeFirst="false">202-03-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="true">base/202-03-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-03a" name="XML Base Processing-a">
                <description>202.03a
                  Same as 202.03 (V-03) but instead readMeFirst on linkbase, the readMeFirst is on the xsd.
                </description>
                <data>
                        <xsd readMeFirst="true">202-03a-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="false">base/202-03a-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-03b" name="XML Base Processing-b">
                <description>202.03b
                  Same as 202.03 (V-03) but instead of Xsd base for linkbase as "./base/", here base is "base/" (without leading ./).
                </description>
                <data>
                        <xsd readMeFirst="true">202-03b-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="false">base/202-03b-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-03c" name="XML Base Processing-c">
                <description>202.03c
                  Same as 202.03 (V-03) but instead of Xsd base for linkbase as "./base/", here base is "./base" (without trailing /) so base is actually the parent (this directory) where the linkbase isn't.
                </description>
                <data>
                        <xsd readMeFirst="true">202-03c-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="false">base/202-03c-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-03d" name="XML Base Processing-d">
                <description>202.03d
                  Same as 202.03 (V-03) but instead enclosing appinfo has base="base/" and its enclosing annotation has base="base/", so effective base for linkbaseRef is "base/base/".  The surrounding directories have the linkbase file but with invalid locs, so it will fail if enclosing element base's aren't processed correctly.
                </description>
                <data>
                        <xsd readMeFirst="true">202-03d-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="false">base/base/202-03d-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-03e" name="XML Base Processing-e">
                <description>202.03e
                  Same as 202.03d (V-03d), but the linkbaseRef element has base="./base", which will result in an effective base="base/base/base" which is still base/base/ for relative URI resolution, so the valid linkbase is obtained.
                </description>
                <data>
                        <xsd readMeFirst="true">202-03e-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="false">base/base/202-03e-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-03f" name="XML Base Processing-f">
                <description>202.03f
                  The linkbase has an xml:base="base/base/base" which means the relative URIs resolve to base/base/.  The xsd discovery should find the xsd in the base/base/ directory.
                </description>
                <data>
                        <xsd readMeFirst="false">base/base/202-03f-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="true">202-03f-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <!-- Herm: this is commented out because it depends on schemaLocation interaction
        	 with xml:base attribute, which is under discusison and in Base Spec WG.
        	 Also it requires changing to generic arc or some other linkbase resource that
        	 will allow a home-made attribute, because as it is written, IHR points out,
        	 it is schema invalid, due to inappropriate namespace on the attribute of
        	 the label.  The schema-invalid form will be moved to a new directory
        	 of schema-invalid tests.
        <variation id="V-03g" name="XML Base Processing-g">
                <description>202.03g
                  Same as 202.03f (v-03f) but the label has an attribute that is defined in an xsd, with LAX validation, the attribute is a string, the schemaLocation hint has a relative URI which should resolve with the xml:base to the base/base/ directory where the attribute is defined as integer, which should fail schema validation.  If the schemaLocation relative URI is not resolved correctly the attribute will appear valid.
                </description>
                <data>
                        <xsd readMeFirst="false">base/base/202-03g-HrefResolutionXMLBase.xsd</xsd>
                        <linkbase readMeFirst="true">202-03g-HrefResolutionXMLBase-label.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        -->
        <!-- XLink Labels -->
        <!-- xlink arc duplication moved to related-standards/xlink/arc-duplication
        <variation id="V-04" name="XLink Label Counterexample">
                <description>202.04  Arc-type elements connecting the same "from" and "to" labels MUST appear in different extended-type link elements even if the arcrole attributes are equal.  This is an XLink constraint.</description>
                <data>
                        <xsd readMeFirst="false">202-04-XLinkLabelCounterExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-04-XLinkLabelCounterExample-definition.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-04a" name="XLink Label Counterexample, Presentation LB with attributes">
                <description>202.04a.  Similar to 202.04 above, but presentation linkbase uses same arcRole on both arcs and each has the usual XBRL order, use, and priority, to appear like a proper ordinary arc override.</description>
                <data>
                        <xsd readMeFirst="false">202-04a-XLinkLabelCounterExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-04a-XLinkLabelCounterExample-presentation.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-04b" name="XLink Label Counterexample, Label LB with attributes">
                <description>202.04b.  Similar to 202.04 above, but label linkbase uses same arcRole on both arcs and each has the usual XBRL order, use, and priority, to appear like a proper ordinary arc override.</description>
                <data>
                        <xsd readMeFirst="false">202-04b-XLinkLabelCounterExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-04b-XLinkLabelCounterExample-label.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-04c" name="XLink Label Counterexample, custom arc duplicated">
                <description>202.04c.  Similar to 202.04 above, but custom arc uses same arcRole on both arcs and each has the usual XBRL order, use, and priority, to appear like a proper ordinary arc override.  Also, like 220 series tests, the linkbase is in the xsd to be sure that appinfo-contained linkbases are XLink validated.</description>
                <data>
                        <xsd readMeFirst="true">202-04c-XLinkLabelCounterExample.xsd</xsd>
                </data>
                <result expected="invalid"/>
        </variation>
        -->
        <variation id="V-05" name="element scheme locators">
                <description>202.05 element() scheme pointers are legal (Spec 3.5.4)</description>
                <data>
                        <!-- two locators to the same element is legal and element() Scheme is legal)-->
                        <xsd readMeFirst="false">202-05-ElementLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-05-ElementLocatorExample-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-06" name="duplicate locators">
                <description>202.06 Locators with different xlink labels pointing to the same taxonomy element.</description>
                <data>
                        <!-- two locators to the same element and two arcs to a common element - is that legal? -->
                        <xsd readMeFirst="false">202-06-DuplicateLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-06-DuplicateLocatorExample-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-07" name="shorthand pointer locators">
                <description>202.07 shorthand pointers are legal (Spec 3.5.4)</description>
                <data>
                        <!-- two locators to the same element is legal and shorthand pointer is legal)-->
                        <xsd readMeFirst="false">202-07-ShorthandPointerExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-07-ShorthandPointerExample-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-08" name="xpointer scheme locators">
                <description>202.08 xpointer() Scheme pointers are illegal (Spec 3.5.4)</description>
                <data>
                        <!-- two locators to the same element is legal and xpointer() Scheme is illegal)-->
                        <xsd readMeFirst="false">202-08-XPointerLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-08-XPointerLocatorExample-label.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-09" name="valid element scheme locators">
                <description>202.09 element() Scheme pointers are legal (Spec 3.5.4)</description>
                <data>
                        <xsd readMeFirst="false">202-09-ElementSchemeXPointerLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-09-ElementSchemeXPointerLocatorExample-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-10" name="several valid element scheme locators">
                <description>202.10 A sequence of element() Schemes in an X pointer is legal (Spec 3.5.4).  The first of the element schemes does not resolve but the second does.</description>
                <data>
                        <xsd readMeFirst="false">202-10-ElementSchemeXPointerLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-10-ElementSchemeXPointerLocatorExample-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
        <variation id="V-11" name="invalid xmlns scheme after a valid element scheme in a locator XPointer">
                <description>202.11 An xmlns() scheme in an X pointer is illegal in XBRL 2.1 (Spec 3.5.4) even if resolution of that scheme is not attempted because an early scheme resolves.</description>
                <data>
                        <xsd readMeFirst="false">202-11-ElementSchemeXPointerLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-11-ElementSchemeXPointerLocatorExample-label.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-12" name="element scheme resolving to an invalid XML resource for a locator">
                <description>202.12 An element scheme in an X pointer in a label linkbase locator that does not resolve to a concept is illegal. See 5.2.2.1 in the XBRL 2.1 specification.</description>
                <data>
                        <xsd readMeFirst="false">202-12-ElementSchemeXPointerLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-12-ElementSchemeXPointerLocatorExample-label.xml</linkbase>
                </data>
                <result expected="invalid"/>
        </variation>
        <variation id="V-13" name="valid element scheme simple link to a linkbase">
                <description>202.13 An element scheme in an X pointer in a linkbaseRef. See 3.5.1.2 in the XBRL 2.1 specification.</description>
                <data>
                        <xsd readMeFirst="false">202-13-ElementSchemeXPointerLocatorExample.xsd</xsd>
                        <linkbase readMeFirst="true">202-13-ElementSchemeXPointerLocatorExample-label.xml</linkbase>
                </data>
                <result expected="valid"/>
        </variation>
</testcase>

